home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / September 96 / Re ODF Extension bug? < prev    next >
Encoding:
Internet Message Format  |  1996-09-19  |  2.0 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF Extension bug?
  2. Sent:        9/11/96 1:27 PM
  3. Received:    9/11/96 1:27 PM
  4. From:        Greg Friedman <friedman@cognosis.com>
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List
  7.  
  8.  
  9. Erlend.Stav@informatics.sintef.no wrote:
  10. > I have had some probl. related to ODF´s extension mngr during release
  11. >(document closedown), and wonder if it might be a bug in ODF.
  12. >
  13. > I have traced the problem down to the following :
  14. > - the SOMPart first deletes the ext. mngr, then the FWPart
  15. > - the FWPart still has a pointer to the (now invalid) ext. mngr
  16. > - my FWPart (subclass) member variable triggers a ReleaseExtension
  17. > - ReleaseExtension tries to access the non-null, but invalid ext. mngr
  18. >
  19. > A workaround that seems to work is to do PrivSetExtensionManager(NULL) as
  20. >the first thing in my FWParts destructor.
  21. >
  22. > Could someone confirm this to be a bug, or am I doing something wrong?
  23.  
  24. I looked at the code and I agree that it shouldn't work this way. The SOM
  25. part macro should just delete the FW_CPart. FW_CPart's destructor should
  26. destroy the extension manager. It is too late to get this fix into R2, but
  27. it will get rolled into R3.
  28.  
  29. If I understand the fix you describe above, you are preventing a crash, but
  30. you are creating a memory leak.
  31.  
  32. Why does your part have to keep a reference to your extension? A reasonable
  33. interim fix might be to eliminate the need to keep a reference to your
  34. extension. If your part needs to get to your extension, you can always call
  35. FW_CExtensionManager::AcquireExtensionManager. You can use the
  36. allowCreation parameter to control whether or not your part's call to
  37. AcquireExtensionManager should cause the extension to be instantiated.
  38.  
  39. Greg.
  40.  
  41.  
  42. ........................................................................
  43.  Greg Friedman                                       friedman@apple.com
  44.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  45. ........................................................................